While software systems continue to grow in size and complexity, business demands continue to require shorter development cycles. This has led some software developers to compromise on functionality, time to market, and quality of software products. Furthermore, the increased schedule pressures and limited availability of resources and skilled labor can lead to problems such as incomplete design of software products, inefficient testing, poor quality, high development and maintenance costs, and the like. This may lead to poor customer satisfaction and a loss of market share for companies developing software and other products.
To improve product quality, many organizations devote an increasing share of their resources to testing and identifying problem areas related to software and the process of software development. Accordingly, it is not unusual to include a quality assurance team in software development projects to identify defects in the software product during and after development of a software product. By identifying and resolving defects before marketing the product to customers, software developers can assure customers of the reliability of their products, and reduce the occurrence of post-sale software fixes such as patches and upgrades which may frustrate their customers.
Testing and identifying problem areas related to software development may occur at different points or stages in a software development lifecycle. For example, a general software development lifecycle includes a high level requirements/design review, a detailed requirements/design review, code inspection, unit test, system test, system integration test, potentially a performance test, and typically, a user acceptance test. Moreover, as the software development lifecycle proceeds from high level requirements/design review to user acceptance test, costs for detecting and remedying software defects generally increases.
In an effort to rein in cost and time overruns, organizations sometimes develop one or more test plans that consolidate ideas on how to allocate effort for a test project. Test plans may include efforts regarding how to design testing activities and focus for the test project. Planning for a test project (e.g., testing project planning, test project planning, project test planning) normally contains two key levels of planning: macro planning and micro planning.
Macro planning is typically achieved using a top-down approach. Macro planning is most effectively performed in the early stages of a project, and is usually accomplished by comparing the current project to the most appropriate available historical project. The result of macro planning is a high level plan for how to allocate effort and how to design the testing activities and focus. The challenges to macro planning frequently include the ability to find a sufficiently similar historical project on which to base planning decisions for the current test project.
Micro planning is typically achieved using a bottom-up approach, and generally includes very detailed plans for every test to be performed after the Unit Test. For example, a micro plan may define how to run a particular test, including the date(s) for the test, the personnel involved with the test, what to do with the results of the test, etc. As any project moves forward in time, more detailed information (e.g., requirements) become available. Very mature organizations might be able to effectively leverage micro planning by looking at the different characteristics of requirements (e.g., risk, size, complexity associated with each). When an organization can do this, it is able to produce a more granular and precise estimation of the effort required, as well as the specific optimum test focus of each defined activity in the macro plan. However, given the pace of schedules, it is increasingly challenging for projects to produce accurate, timely, and cost effective micro plans.
Although conventional scheduling software is capable of supporting resource allocation efforts on any given project, the task of optimally staffing a test execution project is a more complex problem to solve due to the unknown impact of blocking defects. If test resource allocation is not carefully constructed and maintained, a test project can very quickly become mired in a situation where multiple resources may be delayed or blocked entirely from making progress for unacceptably long periods of time during the test execution window when test dependencies are not adequately identified and analyzed. In these cases, test costs relative to benefits received are significantly higher.
Despite this often severe impact to cost and schedule, conventional tools do not provide the functionality to adequately address these issues. As a result, alternative resource allocation planning for testing typically is not performed since it is largely a manual task and too labor intensive to be delivered in a timely way for projects to benefit from the information. As a result, many projects simply opt to execute against a resource allocation plan that is significantly more costly and less efficient than what could have been achieved because they were unaware a better alternative existed.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described herein above.